I came here with the exact same dilemma -- I need to capture & log the 250 response to all DATA commands. I was about to write a PR myself then saw this. 😄

The semantics of returning an SMTPError on a 250 response seems a little off to me since this isn't really an error condition. My thought on this was to add some kind of additional property to the client struct that was a string called DataResponse or something like that. It just holds the response to the last DATA command issued (when not an error, errors would still be returned as usual). This would also avoid the breaking change to Close() as discussed.

But I'll gladly take this as well. Any indication of whether this is going to be accepted?

@Slugger then I can simply add the same functionality as a callback function in LMTP session.

@Slugger @emersion I updated the PR, let me know your feedback.

I like this approach better for sure. Now I can handle the DATA response as needed via a callback.

@emersion kindly ping

Sorry for the delay. I think in general I'm not a huge fan of callbacks... Could we instead turn the returned io.WriteCloser into something like a *DataCommand, and expose the info message as a method?

Agreed with emersion, I think adding an explicit method looks like better design to me.

I am also not sure if SMTPError is the right type to use here, I would at least create an alias named SMTPResponse or something - some careful refactoring may be needed here.

Do we really need to expose the full response? Is there anything interesting in there apart from the human-readable message?

Usually a message ID from the upstream receiver. My use case at the time was that I was trying to use this as a piece in an email forwarding service and when I forwarded messages upstream I wanted to capture the message id from the receiver for logging, tracking and auditing purposes.

Closing in favor of #263